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DECLARATION PURSUANT TO 37 C.F.R. 1,131 

Sir: 

Andrew John Farnsworth, Affiant herein, states and declares as follows: 

1 . I am an Inventor of the subject patent application of United States Patent 
Application Serial Number 10/673,810. I am an employee of M- Stack, Ltd., the 
assignee herein. 

2. I conceived the invention on or about June 26, 2003 responsive to my 
review of a CR (Change Request) relating to Section 8.2.2.3 of the 3 GPP (Third 
Generation Partnership Project). This section deals generally with temporary 
identifiers that can be used to identify a UE (User Equipment). When I reviewed the 
CR relating to Section 8.2.2.3, 1 realized that the then-existing proposal did not 
properly account for C-RNTI values at a UE in the event that the mobile station enters 
a new celL Specifically, in the then-existing CR, the C-RNTI value at, and 



1 



identifying, the UE subsequent to entry into the new cell might be the C-RNTI value 
given to the UE when in an old cell. 

3. When I realized that the proposal of the CR was inadequate, I prepared and 
sent an email dated June 26, 20003 to my co-worker, co-inventor David Pedlar and 
co-worker Mark Norton, both of whom also are employees of M-Stack Ltd,, to alert 
them of the problem with the CR. A copy of the email is attached hereto as 
Attachment A. 

4. My co-workers and I exchanged emails on June 27, 2003 in which we 
discussed the problem in the then-exisitng CR. 

5. On June 30 3 2003, I sent my co-workers another email In this email, I 
noted that, "the UTRAN needs to be aware of the DCH TrChs when the transition to 
CELLJDCH is made." And, I noted that, for the C-RNTI to be supplied in advance 
means that every Cell that the UE may select when leaving CELL_DCH needs to 
reserve that C-RNTI in case the IE picks that cell or exit to Cell_DCH. A copy of the 
email is attached hereto as Attachment C. 

6. I formalized an invention disclosure that discussed the problem and 
solution, including the solution set forth in, and claimed in, the patent application. 
Although I submitted the formalized invention disclosure on July 22, 2003 , I believe 
that I invented the disclosed invention well prior to that date, namely, on or about 
June 26, 2003, as indicated by the June 26-30, 2003 e-mail exchanges. A copy of the 
formalized invention disclosure is attached hereto as Attachment D. The formalized 
invention disclosure is attached to an email dated July 22, 2003. 

7. I further aver that I did not deliberately suppress or conceal the invention, 
that I never abandoned the invention, and that I acted with diligence to reduce to 
practice and to facilitate the filing of the subject patent application at dates prior to the 
earliest-possible effective date of Sharma (US2005/0009527). 
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8. I further declare that all statements made herein of my own knowledge are 
true and that all statements made on information and belief are believed to be true; 
and further that these statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or imprisonment, or both, 
under Section 1001 of Title 18 of the United States Code, and that such willful false 
statements may jeopardize the validity of the application or any patent issuing 
thereon. 



Respectfully submitted, 



2&* e \ -on. - \ G 
Date 




Andrew John Farnsworth 
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Original Message — 

From: Andy Farnsworth 
Sent: 26 June 2003 17:53 
To: Mark Norton; David Pedlar 
Subject: CR931 Bites Back 

Another lousy CR from 3GPP, as far as I can tell. I think the intent was C-RNTI only 
makes sense in Cell_FACH, so zap it otherwise. 

There seem to be (at least) two holes. In 8.2.2.3, C-RNTI is zapped when entering 
CelLDCH - so far so good. But what if CUC moves from FACH (with C-RNTI, e.g. after a 
periodical cell update in CelLFACH) to CelLDCH - it doesn't appear to state that C-RNTI 
should be zapped. 

And 8.6.3.9 states store C-RNTI (implicitly even in Cell_DCH). 
Any comments? I'll post this on IPR-Standards tomorrow. 
Ta, 

Andy F 
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Original Message — 

From: Andy Farnsworth 
Sent: Friday, June 27, 2003 09:58 
To: Mark Norton; David Pedlar 
Subject: RE: CR931 Bites Back 

What I didn't write yesterday is that the holes described below can lead to the Ue having a C-RNTI from 
an old cell. However, I think this is unlikely to happen in practice. The only ways I can see that it can be 
done are as follows. 

Get a C-RNTI in CellJDCH by one of the methods below. Now move away from the cell from which the 
C-RNTI was supplied. Then transition to Cell_FACH using a Reconfiguration. Now normally one would 
except a C-RNTI and a cell to be specified, and that would overwrite the stale C-RNTI. There are two 
problem cases. 

1. If no cell is specified, a Cell Update is required. If CUC did not contain a C-RNTI and left us in 
Cell_FACH then there would there be a problem because the stale C-RNTI would be used. But a CUC 
with no C-RNTI in response to a Cell Update with cause cell reselection is normally going to lead to 
another Cell Update or Ue returning to Idle, so I don't see why a Utran would ever do that. If it did 

2. If a cell is specified but no C-RNTI is supplied, then a cell update would be required. A CUC with no 
C-RNTI would again allow the stale C-RNTI to be used. 

So in practice, I don't see these holes being a problem. Would you agree? 

Thanks, 
Andy F 

— Original Message — 
From: Mark Norton 
Sent: 27 June 2003 09:29 
To: Andy Farnsworth; David Pedlar 
Subject: RE: CR931 Bites Back 



I think when I did CR931 , I had noticed that the text in 8.2.2.3 said, "after state transition, the UE 
enters CELL_DCH", but that the code change suggested just checked nextRrc state. But I had 
realised that a C-RNTI was of no relevance to CelLDCH so proceeded with the code change 
suggested as it seemed logical. Anything we can do to bring the spec inline with the code seems 
a good plan to me! 

Seriously though, it does appear that the spec is, once again, shown to be lacking. 

Regards 
Mark 
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Robert Kelly 



Sent: 

To: 

Cc: 



Subject: 



From: 



Andy Farnsworth [afarnsworth@rim.com] 

Monday, June 30, 2003 5:45 AM 

David Pedlar 

Mark Norton 

RE: CR931 Bites Back 



Thanks for your response. See in-line responses. 
Andy F 

Original Message — 

From: David Pedlar 

Sent: 30 June 2003 11:11 

To: Andy Farnsworth 

Cc: Mark Norton 

Subject: RE: CR931 Bites Back 

Theres a general problem with the way 25-331 is written, in that rather than them specifying a general rule 
like 'Clear the C-RNTI whenever we enter cellJDCH', they add 'Clear C-RNTI' in all those places in the standard 
where we could be entering cell_DCH. This means that they might miss out some way of getting into cellJDCH, 
causing a bug. And the implementor can only fix the bug if they twig what the general rule should have been. 
[Andy Farnsworth] I agree. 

I can't quite see how your 2nd paragraph relates to (1) and (2). 

[Andy Farnsworth] It sets the scene for the two scenarios - exiting from Cell_DCH when a C-RNTI exists in UE, 
but it is from a cell which won't be selected. 

I do remember you were going to raise a CR some time ago about CUCs without C-RNTIs, and you discussed 
that with Jacky Lam 

and concluded that because the problem could be fixed by specific UTRAN behaviour ( ie always supplying a C- 
RNTI when its 

needed.) that a 3GPP CR might not be accepted. Does that apply here? 

[Andy Farnsworth] Recent CRs seem to be of the form "if such and such occurs, UE behaviour is undefined" 
rather than "if such and such occurs, reject the Utran message as invalid". That is done (I think) to allow UEs to 
remain compatible, but avoid the problem by effectively specifying that Utrans such never send such messages. 
So I think both scenarios require CRs. The previous issue was different in that it involved a missing C-RNTI 
causing the Ue to be required to send a response to CUC, but being unable to do so. 

Another point that might not be relevant, is that I think the standards seem to allow you to set things that are not 
currently being used, (For example you could reconfigure dedicated physical channels while in cell_FACH- 
is that possible?) 

[Andy Farnsworth] You can configure DCH TrChs, but not DCH physical channels, while remaining in 
CelLFACH. 

and the changes would only have an effect later when the resources come into use. If that 

principle applies, then it should be valid to setup a CJRNTI whilst in cellJDCH, and for it only to come into use 

once we have moved from DCH into FACH. 

[Andy Farnsworth] I disagree. In the DCH TrCh case, the Utran needs to be aware of these DCH TrChs when 
the transition to CellJDCH is made. That is tractable. However, for the C-RNTI to be supplied in advance means 
that every Cell that the UE may select when leaving CeliJDCH needs to reserve that C_RNTI in case the UE 
picks that cell on exit to CellJDCH, and that is not tractable. 



david 
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Robert Kelly 



From: 

Sent: 

To: 

Subject: 
Attachments: 



Andy Farnsworth [afarnsworth@rim.com] 
Tuesday, July 22, 2003 6:15 AM 
Luis Estable 

P032 (C014) Clear C-RNTI in CellJDCH 
P032J3learJ>RNTMn J3ell_DCH.zip 



Here is another IDF for review. I've embedded the answer to question 10 in the text box for question 9. I observe that the 
link is not active (maybe due to being in a text box) though it can of course be copied and pasted into a browser. Is there 
a better way of supplying such links? 

«P032_Clear_C-RNTMn_CelLDCH.zip» 

Thanks, 

Andy F 
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Invention Disclosure Form: ID-TBD 



Version 0.1 



Instructions: 

• Fill in all sections of this form. 

• SAVE A LOCAL COPY. 

• Attach your local copy of this form to an email and 
send to patents@rim.net . 



Tracking Information: 

Unique ID: TBD 

(Reserved: To Be Determined (TBD) by the Patent Group) 
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Contact Information: 



Your Information: 

Name: Andy Farnsworth 

Email Address : afarnsworth@rim.net 
Phone ext: 

RIM Location: RIM Europe 



Yonr Supervisor's Information: 

Name: Rob Harrison 

Email Address: rharrison@rim.net 
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Short Title: Clear C-RNTI In Cell_DCH 



Question 1 

Who are the people whom you would consider to be inventors for this invention? 
Please list their names and email addresses, include yourself if you believe you are 
an inventor: 



Andy Farnsworth — afarsworth@rim.net 
David Pedlar dpedlar@rim.net 



Question 2 

Into which projects and/or products, if any, might the invention be incorporated? 
Please mark with a check. 



Li BlackBerry Enterprise Server 
O BlackBerry Handheld Software 

□ BlackBerry Wireless Handheld Mobitex and/or DataTAC 

□ BlackBerry Wireless Handheld GPRS 

□ BlackBerry Wireless Handheld iDEN 

□ BlackBerry Wireless Handheld CDMA 
Q BlackBerry Wireless Handheld Edge 
IEI BlackBerry Wireless Handheld UMTS 

□ Relay 

□ SDK 

^ Other: Other UMTS handhelds or Utran equipment 



Question 3; 

Are you aware of any date(s) on which the invention, a product incorporating the 
invention, or any details relating to the invention may have been or is going to be 
released outside of RIM? If so, please provide the dates of any such releases. 

A Change Request to the UMTS standard 25.331 is being prepared by the RIM Standards 
Group (Nick Alfano et al.) and may be contributed by RIM or M-Stack, possibly as soon 
as August 25 th 2003. 

Question 4: 

What do you call your invention (long title)? 

Ensuring C-RNTI is cleared in Cell J)CH 
Question 5 

RIM Confidential and/or Sollicitor-Client Privileged Work Product 
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Version 0.1 

How would you characterize the nature or technical field of the invention? For 
example, this invention relates to software virus protection for mobile 
communication devices. 

This invention relates to UMTS protocol stacks and 3G mobile devices in general, and to 
software that includes a User Equipment UMTS protocol stack, e.g. that which may 
reside in a 3G mobile phone. 

Question 6 

What problem(s) does this invention address? Describe in detail. 

In UMTS, Cell Radio Network Temporary Identifiers (C-RNTIs) are alloacted by each 
cell in the UTRAN to each User Equipment (UE) that is in that cell and is in Cell_FACH. 
When the UE leaves CellFACH or leaves the Cell, the C-RNTI is no longer required by 
the UE, and should be deleted so that the Utran may reallocate the C-RNTI to a different 
UE. 

Unfortunately, the attempt in CR931 failed to ensure that C-RNTI was cleared when 
entering Cell_DCH. Thus a UE can exit Cell_DCH with a C-RNTI from another Cell, 
which may be allocated to another UE, thus causing interference. 

Question 7 

How does the invention solve the problem(s) identified in question 6? Describe in 
detail. 

The invention is a deviation from the UMTS protocol defined in the 3 GPP document 
25.331 v3.13.0. 

There are a number of ways in which the UE can enter CellJDCH with a C-RNTI, and so 
each of these need to be addressed. 

A. Cell Update Confirm 

If Cell Update Confirm moves from FACH (with C-RNTI, e.g. after a periodical cell 
update in CellFACH) to Cell__DCH, it is proposed that C-RNTI is cleared. 

This corresponds to a proposed change to section 8.3.1.6. 

B. RRC Connection Setup 

It is proposed that the scenario where RRC Connection Setup moves to Cell__DCH but 

also provides a C-RNTI should be addressed. There are several possible solutions here. 

B. 1 Ensure the Utran never sends such a message; 

B.2 UE should reject such a message as invalid; 

B.3 UE should ignore such a message; 

B.4 UE should move to CellJDCH, but ignore the C-RNTI; 

RIM Confidential and/or Sollicitor-CIient Privileged Work Product 
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Invention Disclosure Form: ID-TBD 



Version 0.1 

B.5 UE should move to Cell_FACH and ignore the CellJDCH state indicator; or 

B. 6 UE should take some other action that ensures it is not in Cell_DCH with a C-RNTI. 

Options B.l to B.4 would correspond to a proposed change to section 8.1.3.6. 

C. New C-RNTI 

It is proposed that when a new C-RNTI is received, and the the UE will remain in or 
transition to CellJDCH, then some action is taken to avoid being in Cell_DCH with a C- 
RNTI. Again several solutions exist for this scenario. 
C. 1 Ensure the Utran never sends such a message; 
C.2 UE should reject such a message as invalid; 
C.3 UE should ignore such a message; 

C.4 UE should remain in (or transition to) CellJDCH, but ignore the C-RNTI; 

C.5 UE should move to CellJFACH if required and perform CeUJJpdate; or 

C.6 UE should take some other action that ensures it is not in CellJDCH with a C-RNTI 

Some of these options correspond to a proposed change to section 8.6.3.9, and possibly 
other sections. 

Question 8 

Are you aware of any existing solutions that attempt to address the problem(s) 
outlined in question 6, if so please list them and provide a brief summary. Please 
spend a few minutes to search the web using www.google.com and provide the two 
most relevant solutions you find. (Note: You can paste specific URLs.) 

Solutions are given in CR931 to 25.331 for the case where a reconfiguration message 
transitions to Cell_DCH - see 8.2.2.3. 

Question 9 

For each solution listed in question 8, how is your solution different? If no existing 
solutions were found in answer to question 8, please proceed to question 10. 
Otherwise, how is this invention different from these existing solutions? Describe in 
detail. 

The solution in 8.2.2.3 does not cover the cases A-C described above, as those cases 
involve messages other than reconfiguration messages. 

Answer to Question 10: 

See IPR-Standards-CR thread "Ensuring C-RNTI is cleared in Cell__DCH M : 
http://livelinMivelinM^ 

Question 10 
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Version 0.1 

Are you able to provide any documents that relate to this invention (i.e. design 
documents, specifications, drawings, sketches, flowcharts, rough ideas, etc)? If so, 
please attach the file(s) when submitting this document by email to 
patents@rim.net . 
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